Run the dependency update wave and harden cascade - #5

`prep` pulls the consumer's base branch, which moves the recorded `config`
pointer but not its checkout, so the tree looked dirty and `prep` stopped.
A repository whose `config` submodule was never initialized passed for one
that does not consume `config` and silently skipped the pull. `prep` now runs
`git submodule update --init -- config` right after branching.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Cascade waves run clean builds routinely; the owner approved moving the rule
from "ask" to "allow".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`cascade graph` saw local objects only as `Obj.member` or
`io.spine.dependency.local.Obj.member`. Build scripts that load the Compiler
through `config`'s accessors — `classpath(spineCompiler.pluginLib)` in
`core-jvm` and `jdbc-storage` — therefore had no `compiler` edge, so waves never
re-pinned the Compiler there. Those repos then built against the published
Compiler and its transitive tool-base artifacts, which bundle an older Protobuf
runtime.

The derivation now treats `spineCompiler.member` and `coreJvmCompiler.member`
like their objects (references in `force(...)` still create no edge), and
`id(<accessor>.pluginId)` as a plugin application. The regenerated graph gains
`compiler -> core-jvm` and `compiler -> jdbc-storage`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Address the documentation review: name the accessors that have a `pluginId`
form, say what the false `prep` error is, and quote `delivery` as a name.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`cascade` took the registry serving a repo's marker artifact as proof of a
complete publish. A `publish.yml` run that fails midway has already uploaded
some modules: compiler `.072` reached the registry without `compiler-testlib`,
`cascade` marked it `published-remote`, and `validation` shipped into a CI that
could not resolve the missing module.

`publish_verdict` now reads the conclusion of the `publish.yml` run for the
merge commit of the repo's wave PR. A failed run yields the new state
`publish-failed` (with the run linked in `status` and a `FIX-PUBLISH` action),
a running one stays `merged`, and `ship` refuses an upstream whose publish
failed. Without a recorded PR or run, the registry remains the evidence.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A repo counted as published as soon as the registry served its wave target
version. When the base branch takes the same version first, that copy is the
base branch's build, not the wave's: core-jvm `.571` merged on master while
the wave's `.571` was still unshipped, so `status` showed it published and
downstream repos would have shipped against it.

`cascade` now requires the wave's own PR to have merged. Otherwise the state
is `collision`, and `next` asks to `REBUMP` the repo. `ship` refuses such an
upstream, and also an upstream whose target moved past the recorded pin while
the old pin stays public.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Name the repo whose wave PR must merge, document exit 3 from the upstream gate, and align the `FIX-PUBLISH` and `REBUMP` re-pin instructions.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`./cascade refresh <repo>` on a `publish-failed` repository now starts it over from the base branch (the wave branch has merged), so `prep` pulls `config` again and bumps past the partly published version. `ship` and `derive_state` look for the wave branch's open PR, not any PR from that branch name, which would find the merged one.

`prep` reads its earlier pull commit through a here-string: under `pipefail`, `git log | grep -q` could read the SIGPIPE `git log` takes as "not pulled" and pull `config` a second time.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

GitHub dropped the push event of the time `.252` merge, so no workflow started for the merge commit, and the wave read the repository as `merged` forever. Ten minutes after a merge without a `publish.yml` run, `publish_verdict` now reports a failure, which routes the repository to `FIX-PUBLISH` and lets `./cascade refresh` re-ship it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The push event of the time `.252` merge arrived 17 minutes late, during a GitHub incident, so its Publish run did start and succeed; ten minutes was too short to tell a dropped event from a delayed one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Two `cascade` runs at once (the driver's `next` and a manual one) shared `<manifest>.tmp`: one truncated the other's output, and an empty manifest was moved into place, which `next` then read as a finished wave (CLOSE). `mset` now writes through a private temp file and never moves an empty result into place, and `next` and `close` refuse a manifest that lists no repos.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Without the mapping, `close` skipped `DokkaTools.kt` and left `config` pinning `2.0.0-SNAPSHOT.10` after the wave published `.12`, and the floor gate could not tell which repo a `DokkaTools` pin belongs to.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`close --ship` still opened the closing PR as ready, so the organization's ruleset requested a Copilot review before CI had run, as `ship` already avoids. Mark it ready once all its checks pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

config#818 (merged as `fcd68830`) records the version vector the wave published; the log ends with the events since 2026-10-21.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>